This is a really interesting idea, and I see the value in it, but I have deep reservations about whether this is the right way to implement it. The fundamental issue is with maintaining the 'completed' state. Exiting the loop is fine within a single local Spin instance, but what happens when that instance restarts - for example, because spin watch restarts it, or because you need to update the app, or because the computer needs to be rebooted, or because the VM is being upgraded and the workload needs to be moved to a different VM? Because all we've done is exit the timer loop in the original instance, the new instance has no memory that the component's work is done, and starts a new timer loop for it. We are relying on transient program flow in the host rather than structured, persistent application state.

And right now I don't have a better solution. Better solutions may be hard: Spin has an unarticulated design philosophy that not only are component instances stateless, but even the runtime itself is sorta-kinda stateless (stateful within a session for sure, but between sessions, not so much) - everything should be in the manifest. This shows up particularly in the cloud where applications can be evicted and rehydrated willy-nilly. A feature like this requires a concept of application state that we just don't have at the moment.

So I am not sure how to proceed. Part of me doesn't want to turn a simple PR into a vast and foundational architectural investigation. But at the same time, I don't feel comfortable introducing this behaviour ad hoc without thinking through the architectural implications (particularly for a sample that is meant to guide others).

I hope this makes sense, and I'd be interested to hear how you and other Spin folks feel about this and how to manage it. Thanks for the PR and for all the thoughts it has sparked!

Thanks @itowlson, I don't disagree with what you alluded to above, it's a valid concern. One way of thinking about this is that we can decouple the application level state management from Spin framework (to your point keeping it stateless) and let the components handle state between restarts as per their business logic and state store options provide by Spin e.g. KV store on a single machine or Redis if it's running on multiple machines, as an example. This is how I am addressing some of these concerns in my local branch where app restarts do not lose this state, as the state is maintained in KV store (single machine use-case).
I guess the other example of this pattern where state is maintained externally would be where we checkpoint the events from Azure Events Hub as we read them, this process can run for a long time and we may need app/vm/host restarts in-between for the very same reason you forementioned.

Would welcome yours/others thoughts on it.
Ideally, I'd prefer to have http 202/accept pattern in Spin along side this polling/timer trigger to allow e2e service composition but that's something for another PR/issue (we discussed some of it in Discord).